xsm/evtchn: never pretend to have successfully created a Xen event channel

Xen event channels are not internal resources.  They still have one end in a
domain, and are created at the request of privileged domains.  This logic
which "successfully" creates a Xen event channel opens up undesirable failure
cases with ill-specified XSM policies.

If a domain is permitted to create ioreq servers or memevent listeners, but
not to create event channels, the ioreq/memevent creation will succeed but
attempting to bind the returned event channel will fail without any indication
of a permission error.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 18a76af8e1a5572ffbdeb4f060b5161ddcd7e3c4..c0fbcea7482f5c91398e85a2483072a8f3b8a380 100644 (file)
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1148,21 +1148,25 @@ int alloc_unbound_xen_event_channel(
 
     spin_lock(&d->event_lock);
 
-    if ( (port = get_free_port(d)) < 0 )
+    rc = get_free_port(d);
+    if ( rc < 0 )
         goto out;
+    port = rc;
     chn = evtchn_from_port(d, port);
 
     rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, remote_domid);
+    if ( rc )
+        goto out;
 
     chn->state = ECS_UNBOUND;
     chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
-    chn->u.unbound.remote_domid = !rc ? remote_domid : DOMID_INVALID;
+    chn->u.unbound.remote_domid = remote_domid;
 
  out:
     spin_unlock(&d->event_lock);
 
-    return port;
+    return rc < 0 ? rc : port;
 }